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ABSTRACT 


A Low Earth Orbiting ‘‘Pacsat’”’ has been described in the past as an orbiting bulletin board 
system. This is an over-simplification. A PACSAT is a multi-channel, full duplex device, 
with short, periodic access times dictated by orbital mechanics. These attributes mandate a 
different approach than the standard command-line interpreter style of BBS if the full poten- 


tial of a PACSAT is to be realized. 


The authors propose a new methodology for a PACSAT, and have developed several new 
protocols to implement more efficient access. These protocols all use AX.25, either in con- 
nected mode or with UI] frames. This paper provides a description of the access model. and 


an overview of the new protocols. 


Background 


The authors have been struggling with the ques- 
tion “How can we make the best use of a band- 
width-limited low earth orbiting digital store-and- 
forward svstem with a worldwide, unstructured? 
heterogeneous user base” since an amateur Packet 
Radio satellite was first discussed in 1982. We be- 
gan on air experimentation with the UoSAT-2 
(UO-11) Digital Communications Experiment in 
December, 1984. In the following five and one 
half years, we’ve looked at where a resource like a 
PACSAT best fits in to the network as a whole. 
As a result of our study, we are proposing the use 
of a broadcast protocol as the basic downlink 
method, and a “file server” rather than a BBS ap- 
plication as the basic service offered. This docu- 
ment provides a brief overview of these conclu- 
sions, the companion specification documents pro- 
vide the implementation details. 


This paper and the companion protocol specifica- 
tion papers assume that the reader has a basic 
understanding of the current packet radio satel- 
lites, for additional background. see references [1] 
through (6). 


PACSAT 


PACSAT is generic term in the amateur radio ser- 
vice for a low earth orbiting spacecraft which car- 


ries a large on-board memory for the purpose of 
data storage and retrieval by groundstations. A 
PACSAT can be the entire mission of a spacecraft. 
such as AMSAT-NA’s AO-16, or a minor adjunct. 
such as the DCE on UO-11. The paper refers to 
the current “PACSAT” spacecraft - the University 
of Surrey’s UoSAT-3 (UO-14) and the AMSAT 
Microsats AO-16 and LO-19. These spacecraft 
will be the hosts of software developed by the 
authors which implements the protocols described 
herein. 


Each of these spacecraft are different. AO-16 and 
LO-19 are the most closely related, based on AM- 
SAT’s Microsa t design. From the user's point of 
view, they have four 1200 bps uplinks and one 
1200 bps downlink. These are switchable to 4800 
bps, but no ground modems exist at this time. 
UO-14 has a single uplink and downlink, at 9600 
bps. Although the onboard computers are differ- 
ent, they are compatible at the application soft- 
ware level, permitting the same software to be 
used on all three. 


In spite of these differences? all of these spacecraft 
share the following attribute: each is a bandwidth 
limited device. The number of uplinks and down- 
links is much less than the number of users, and 
the capacity of the link is much less than the of- 
fered load. Each is only visible to a particular user 
for about 14 minutes, four or five times a dav at 
middle latitudes. We feel that this is the critical 
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design driver, and the access methods must be op- 
timized with this in view. 


Keep in mind, however, that even while subject to 
access time limitations, the satellites can still move 
a prodigious amount of data, especially when 
compared to the current amateur radio long haul 
network standards. A typical gateway station, 
moving traffic from the US to the UK on 20MHz 
at 300 baud, assuming the band is open for 16 
hours, could move 1.7 million bytes of data per 
day, if the link was 100% efficient. The average 
HF link is not 100% efficient, at best it is perhaps 
30% efficient. The link is only half duplex, so this 
data transfer is only way only. 


UO-14, even with only 56 minutes of access time 
per day at 9600 baud, can move 3.2 million bytes 
of data in one direction. The excellent link quality 
of the current PACSATs, combined with their full 
duplex nature and the protocols we are proposing, 
can approach 90% efficiency. Full duplex means 
transfers can occur in both directions simultane- 
ously, so that UO-14 could move nearly 5.7 mil- 
lion bytes of data between the US and the UK in a 
24 hour period, vs. .5 million bytes over an HF cir- 
cuit. 


The desire to realize this potential is the reason we 
choose some non-traditional (for the amateur ra- 
dio service) access methods for PACSAT. These 
methods, broadcasting and file server, are dis- 
cussed below. 


Broadcasting 


A spacecraft is inherently a broadcast device. It 
transmits from on high, and many users can hear it 
at the same time. 


To optimize the available downlink time, we are 
recommending the use of a broadcast protocol. 
This protocol adds information to the basic Ax.25 
data frame to permit many stations to make si- 
multaneous use of a single file download session. 
When one station in Maryland requests the current 
orbital element sets, there is no need for stations 
in Toronto and Miami to do the same, they should 
be able to make use of the information as it is 
downlinked to Maryland if they are all in view of 
the satellite at the same time. To make use of a 
broadcasted frame of data, each frame must be 
tagged with the file it belongs to and the position 
within that file that the data belongs in. 


204 


There should also be enough information for a 
station to determine if it has all of tbe data be- 
longing to a file, and if not, to request that just the 
missing parts of the file be retransmitted. The 
specification titled “PACSAT Broadcast Protocol” 
describes a method of providing this additional in- 
formation. 


With a broadcast protocol, a groundstation can 
simply monitor the downlink and accumulate files 
of data. Since files gathered in this way will have 
been unsolicited, the format of the contents may 
not be known to the user. For example, if one 
asked for a file of NASA format orbital elements, 
one can make a good guess that the resulting file 
contains NASA format orbital elements. However, 
if a “random” file is captured, its contents may not 
be understandable simply from inspection. Some 
addition information, such as a file name, data 
type, description, creation date, etc., may be re- 
quired. Each broadcasted file? therefore, needs a 
header in a standard format with this information. 
The specification titled “PACSAT File Header 
Definition” describes a method of providing this 
information. 


We hope that the broadcast protocol promote effi- 
cient use of the downlink. It should reduce the 
number of requests for files of general interest. It 
should also reduce the uplink loading. since a 
broadcasted file does not receive an ack for each 
frame or group of frames. In the best case, only 
one “ack” is sent for an entire file, and that would 
be the request to stop broadcasting it. 


Even though the sky-to-ground link is broadcast in 
nature, the ground-to-sky link is not. PACSAT 
“sees” many ground stations at one time. For this 
reason? a ‘connected-mode, non broadcast file 
transfer method is also defined. and is described in 
the paper on “PACSAT File Transfer Level 0”. 


File Server 


As a data transfer and storage device. a PACSAT 
can serve a multitude of purposes. It can store 
telemetry, digitized voice and video images, per- 
sonal mail, forwarded mail, or anything else the 
can be stored in a computer file. Mail forwarding 
is a good example of an excellent use of a PAC- 
SAT. AO-16’s 1200 baud link could easily be 
used to transfer 240k bytes of uncompressed for- 
warded mail in each direction between California 
and England in 24 hours, with just one moring 


and evening pass over each location. UO-14’s 9600 
baud link could move 1.6 Mb of data in the Same 
time. A PACSAT can store up to 8Mb of data. 
This would make a powerful addition to the cur- 
rent HF relay network. 


The problem, however, is that the current amateur 
network is in a state of flux. New addressing 
schemes are proposed every few weeks, new 
routes and new ways of routing are proposed, 
tried, discarded or modified. This is good. Im- 
plementing the software on a spacecraft to follow 
these shifting designs is difficult, however. The 
testing required for the spacecraft is more rigor- 
ous, especially on the Microsats, where the same 
computer is used for the BBS and to keep the 
batteries charged. Faulty forwarding code could 
crash the computer, which could cause damage to 
the batteries or reduce their life expectancy. 


The amount of program memory is limited on the 
spacecraft as well. To counter the effects of high 
energy particles above the earth’s atmosphere 
which cause memory bits to be changed, the 
PACSATs use 12 bits to store 8 bits of program 
data. The extra bits are used to correct for single 
bit errors. To keep the cost down, and to reduce 
the power used (AO-16’s CPU uses about 500 
milliwatts, on average), only 256k bytes of pro- 
gram space is available. (This should not be con- 
fused with the message storage space, which is 
much larger than the program memory, and is 
protected with a software algorithm using three 3 
bytes to protect 253 bytes of data. Because this 
memory is protected with software, it is not suit- 
able for storing a running program, since a pro- 
gram can not protect its executing instruction.) 


We have a desire, then, to keep the spacecraft 
code simple and stable, while still allowing it to be 
a useful part of the changing amateur network. 


We propose that the spacecraft be primarily used 
as a file server, moving data files from one point 
to another. The PACSAT would have no knowl- 
edge of the contents of the files, nor would it take 
an active role in the forwarding of mail messages. 
Groundbased software could, however, make the 
PACSAT system look like a familiar BBS to the 
user, and it could intelligently forward mail. 


A PACSAT will know how to receive and trans- 
mit a standard file format. All files will have a 
standard header, the same one that is used by the 
broadcast protocol. It will also know how to select 


files for transmission based on the contents of the 
header. This feature can then be used by ground- 
station software to emulate any desired user inter- 
face. 


For example, assume that a user wanted to send a 
personal mail message to a friend. In the current 
terrestrial environment, he would connect to a 
BBS, which would lead him in a question and an- 
swer session something like this: 


Remote Computer User 


What do you want? Send message 


To whom? Fred 
Title? Club meeting 
Message? Meeting at 8 p.m. 


What do you want? Read new mail. 


Message #200 


sees 


Using the PACSAT system, exactly the same ex- 
change would take place, except that the conver- 
sation is between the user and his local computer. 
The message is stored for later transmission to a 
PACSAT. The read new mail request is also 
stored. The next time the PACSAT comes over- 
head, the computer does the following: 


1) builds a file with a standard PACSAT header. 
The header says that the file contains a mail mes- 
sage, from you, to Fred. 


2) The file is compressed: and sent to PACSAT. 


3) The local computer then sends a message to 
PACSAT that says “send the next file who’s 
header meets the following criteria: it’s a mail 
message type. the destination is me. and the file 
number is bigger than x”. 


“%’? is the number of the last file received on the 
ground, and is kept by the local computer. After 
the pass, the local computer can now print any 
new mail received. To the user, it looked pretty 
much the same. 


What about file forwarding? A gateway would 
need to know what type of mail it could forward. 
Let’s assume that the routing scheme of the week 
is based on a hierarchical string containing states. 
like nk6k.ca.usa, and this gateway handles mail to 
CA, NV, and OR. The gateway would send a 
message to PACSAT containing the following re- 
quest: 
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“Send the next file who’s header meets the fol- 
lowing criteria: it’s a forwarded message, and the 
destination string contains ”?.ca.?’ or ’?.nv.?’ or 
”?,0r.?’, and the download count is 0.” 


The file would be received, decompressed, and 
imported into the standard BBS program after the 
pass. 


In this way, the ground program can be as simple 
or as complex as required, the PACSAT only 
needs to know bow to select a file for transmission 
based on the contents of fields in the standard file 
header. 


Summary 


These two ideas, broadcasting and file server, are 
certainly different than the current common usage 
of packet radio on the amateur bands. We feel 
that this is the best approach for the special case 
of a PACSAT, however, and that with suitable 
groundstation software. these concepts can be in- 
tegrated into the mainstream. 


Implementation Status 


Prototype implementations of all of the protocols 
discussed in this group of papers are running on 
UO-14 as of late July, they should be running on 
the Microsats by the time of the ARRL confer- 
ence. Prototype ground software is also running. 
We plan to make the source code for simple ver- 
sions of the ground portion of the system available 
asap. Executable versions for the IBM PC will be 
made available as shareware, with the proceeds 
going to AMSAT-UK and AMSAT-NA to further 
developement of future PACSATs. Fully inte- 
grated, automated, color graphic, “all singing and 
dancing” software will be available for sale bv 
AMSAT-UK and AMSAT-NA later in the year. 
Like QUICKTRAK and InstantTrak, the proceeds 
from this commerical quality software will go to 
finance future amateur satellite endevours. 


We hope that other software authors will use the 
documentation and source to develop support for 
non IBM PC systems. The contents of these pa- 
pers are sufficient to allow programmers to begin 
implementing their own software now. 
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